This disclosure relates to a computer processing system for transactional memory operations, and in particular to a Hybrid Transactional Memory System (HybridTM).
Multicore microprocessors, as Intel's and AMD's dual core and quad core chips or Sun Microsystems's Niagara or RockHTM, known as HTMs using large numbers of hardware threads of execution are currently being used in computing servers. The server software industry is moving towards new programming techniques to increase the concurrency of existing software in order to allow applications to take advantage of the large number of threads.
A Hybrid Transactional Memory System (HybridTM) has been thought to provide a good tradeoff between hardware complexity and cost vs. overall system performance when executing transactions.
Most existing HybridTM systems provide hardware support as a Hardware Transactional Memory (HTM) like the illustrated CPU microprocessor core element in FIG. 1 of this application for some transactions and use a Software Transactional Memory (STM) system to handle others. To be cost effective, the hardware is limited in the number of storage locations that can be tracked. An example of a HybridTM system is one which can execute short transactions very quickly using a small amount of hardware but uses an STM system for long transactions that contain many storage references. The hardware may also be limited in the types of system operations that can be used while executing a transaction. These limitations cause some transaction to fail repeatedly. HybridTM systems must deal with these failures in some manner.
A significant drawback of these HybridTM systems is the fact that only code that has been generated by a Transactional Memory capable compiler can be used The code inside of transactions needs to be instrumented with calls to the STM software interface and therefore must be compiled together with STM in order to know which loads and stores should be instrumented. Dynamically compiled code can get around this limitation but carries other limitations related to speed and efficiency of compilation. Another drawback is that existing STM implementations have very long pathlengths and are therefore slow. This becomes a performance problem for applications which use Transactional Memory and fall back to the STM support often. Nevertheless, most recently HybridTM systems have been developed which exploit STM on HTM systems and provide for executing, one or more transactions in a first transactional memory mode while all transactions executed in the execution environment are executed according to a particular transactional memory implementation; and they try to dynamically transition to a second transactional memory mode during runtime; executing one or more transactions in the second transactional memory mode, while in said second transactional memory mode all transactions are executed according to a different transactional memory implementation than in the first transactional memory mode; where either the particular transactional memory implementation or the different transactional memory implementation is a hybrid transactional memory implementation in which some conflicts in the shared transactional memory space between transactions are resolved by a full STM software implementation without hardware support and other conflicts in the shared transactional memory space between transactions are resolved by a HTM hardware implementation.
Another alternative type of HybridTM system is one that doesn't require a full STM system. In this alternative the software programmer is required to provide both a Transactional Memory software path and an additional lock based path for their code. If a transaction fails repeatedly, the system forces the use of the lock based path. Although this type of system does allow the use of a limited hardware transactional memory (HTM) design, it is not desirable to build a lock based path for all the transactional code.
A third method of providing a backup for a hardware transactional memory HTM system that provides limited hardware resources. It has been suggested that the HTM system can “stop the world” and let one problem transaction run by itself. This has been referred to as granting one “favored” transaction. This solution will not work well for systems that provide dozens of threads of execution.